[レポート]デバイス、クラウドの双方向通信 デザインパターンと実践 – SORACOM Technology Camp 2020 #SORACOM

[レポート]デバイス、クラウドの双方向通信 デザインパターンと実践 – SORACOM Technology Camp 2020 #SORACOM

「SORACOM Technology Camp 2020」のセッション「デバイス、クラウドの双方向通信 デザインパターンと実践」に関する視聴レポートです!
Clock Icon2020.11.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2020年11月に開催されたイベントSORACOM Technology Camp 2020で行われた以下のセッションに参加しましたのでレポートしたいと思います。

セッション情報

概要

接点を閉じる、カメラをONにする、ロボットに新たな命令を与える。こういった作業を遠隔から行いたいと思ったことはありませんか? 本セッションでは、IoTデバイスに対してクラウドからデータやコマンドを送信するための手法とその実装方法を網羅的にご紹介します。

スピーカー

須田 桂伍 様
株式会社ソラコム
ソリューションアーキテクト

soracom-tech-camp-day2-design-pattern-01

上記の流れで本セッションは進みます。

soracom-tech-camp-day2-design-pattern-03

  • IoTのシーンでは、「モノ」「インターネット」「クラウド」の3要素が出てくる
  • それぞれの各通信の方向を上記内容にて定義してセッションを進めます

soracom-tech-camp-day2-design-pattern-04

  • 要件や設計をシンプルにすることが重要
    • 本当に双方向通信が必要ですか?

soracom-tech-camp-day2-design-pattern-05

  • 例えば電源という考慮点だと
    • 「バッテリー駆動だとデータ送信時だけ起動」にすると消費電力を抑えることができる
    • しかし、それだとクラウドから操作したい時にアクセスできない場合がある

soracom-tech-camp-day2-design-pattern-06

  • アプリケーション観点での考慮点
  • データ到達保証
    • データが届いてるか
    • データが届いているとして、正常に処理されているか
    • クラウドからデバイスを動かす場合、データが届いてるか認識されずリトライされて2重処理で予期せぬ挙動となる場合もある
    • そのために必要に応じて重複処理を排除する仕組みが必要になることも

soracom-tech-camp-day2-design-pattern-07

  • 「双方向通信の費用対効果」を考える

soracom-tech-camp-day2-design-pattern-08

  • 全体を見て最適化するのが望ましい

(IoTは総合格闘技と言われる所以な気がしました。)

soracom-tech-camp-day2-design-pattern-09

次からは、双方向通信のデザインパターンの紹介です。

IPアクセスパターン

soracom-tech-camp-day2-design-pattern-11

  • IPアドレスで通信するパターン
  • 通信のセキュア化が課題

soracom-tech-camp-day2-design-pattern-12

  • SORACOMのCanal、Door、Directでユーザーのサーバにアクセス

soracom-tech-camp-day2-design-pattern-13

  • SORACOM Canal はAWS環境と SORACOM を AWSの「VPCピアリング」でプライベート接続します。
  • VPCピアリングが利用できない環境だと、Door や Direct を使います。
    • 個人的には、Canalが出る以前は Door を使ってInternet VPN接続していたことがあります。

soracom-tech-camp-day2-design-pattern-14

  • 上記の場合、Gate peerというサーバを建ててアクセス
  • 詳細は下記などを参照

soracom-tech-camp-day2-design-pattern-15

  • Napterでデバイスにオンデマンドにリモートアクセス
  • Napterで一時的にアクセスできるエンドポイントが払い出される
  • APIで払い出しもできるのでアプリケーションによるシステムチックな処理も可能

soracom-tech-camp-day2-design-pattern-16

  • GateとNapterの使い分け
  • 通信が定常的 or オンデマンド で分ける

アプリケーションパターン

soracom-tech-camp-day2-design-pattern-18

soracom-tech-camp-day2-design-pattern-19

  • Beam、Inventory、SMS API

soracom-tech-camp-day2-design-pattern-20

  • Beamでプロトコル変換が可能
    • MQTTをサポートしているのでPub/Sub通信が可能

soracom-tech-camp-day2-design-pattern-22

  • SMS方式
  • APIで送信してデバイス側で本文から命令の読み取り・実行

デバイスリードパターン

soracom-tech-camp-day2-design-pattern-24

  • 「デバイスからの上りの通信」を利用するパターン
  • リクエスト/レスポンス方式
  • ポーリング方式

soracom-tech-camp-day2-design-pattern-25

  • BeamにReq/Res方式
    • サーバ側でHTTPレスポンスをデバイスに返す
    • Funkの場合
      • LambdaなどFaaSの関数の戻り値を返す

soracom-tech-camp-day2-design-pattern-26

  • メタデータサービスをAPIで直接呼ぶ
  • Orbitでメタデータを取り出して応答に埋め込む
  • メタデータに格納したスクリプトにアクセスしてデバイス側で実行することも可能

soracom-tech-camp-day2-design-pattern-27

  • 上記画面のように、SORACOMコンソール上でユーザーデータにスクリプトを格納できる

soracom-tech-camp-day2-design-pattern-29

soracom-tech-camp-day2-design-pattern-30

質疑応答

  • これだけ複数のプロトコルやタスクの連携になると デバッグやトラブル切り分けが大変そうですが、どのようなツールで開発、メンテされているのでしょうか?
    • デバッグ方法の1つとして、ツールの観点だとデバイスリードパターンでOrbitでデバッグログを使う、Funkならクラウドサービス側でログを出すなど。
    • ソラコムのコンソール上からセッション状況などを見て地道に切り分け
    • 特殊なツールなどを使っているということはない。
  • BeamのTCPによる中継は、たとえばSMTPのような通信でも可能なのでしょうか?
    • 一部制約もあるので後ほど確認します
  • Napterを使わせていただいてます。IPで接続 ラズパイのサーバーを開いてます。ラズパイのGUI初期画面を開くには、他のアプリを使うのでしょうか(例えば、接続元からvncクライアントでひらく?)
    • VNCのクライアントを使ってアクセスされる例が多い
  • 様々な機能の選択にはノウハウが必要と思われますが、具体例を示したような資料はどこかにありませんか?
    • 本セッションの資料とか。過去のブートキャンプの双方向通信の資料もみてほしい。
    • 後はお客様事例なども参考になるかと。
    • 不明点などあれば問い合わせいただければ。
  • MQ(MessageQueue)利用の利点、配慮するところあれば教えてください。
    • システム連携を疎結合にできる点です。疎結合にすることでシステム切り替えや拡張性にも優れている。

最後に

本セッションは過去のイベントなどで話された内容を、今回の時間尺に合わせた凝縮版となっているとのことでした。もうすこし詳しい情報が欲しい場合は下記のような過去資料などを参照することで理解を深めることができるのではないかと思います。

個人的には、長尺でもいいのでもっと詳しくじっくりと話を聞いてみたいと思える内容でした。

以上です。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.